Handover is the process of transferring an ongoing communication session, being a voice/video call or a data session, from the current serving cell, further referred to as the source cell, towards a new better-suited cell, further referred to as the target cell. For instance, as a User Equipment (UE) is moving away from the coverage area of a serving cell, the radio signal from that serving cell weakens while the radio signal from another better-suited cell strengthens. When the radio path loss between these two cells is past a predetermined threshold, a handover towards the better-suited cell is triggered. A UE may also be handed over on account of Radio Resource Management (RRM) criterion, for instance because the serving cell gets overloaded.
For Long Term Evolution (LTE) mobile networks, an overview of the handover procedure and related message exchanges is described in § 10.1.2 of the Technical Specification (TS) entitled “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description”, published by the 3rd Generation Partnership Project (3GPP) in June 2009, ref. 3GPP TS 36.300 V9.0.0.
In a first step, the source evolved-NodeB (eNB) configures the UE measurement policy, e.g. the UE is configured to send MEASUREMENT REPORT on a regular basis and/or as soon as a handover event is detected. The measurement reporting period and/or the handover parameters for detecting the handover events are broadcast by the serving cell as part of the system cell information.
In a second step, the source eNB makes a decision to hand off the UE based on the MEASUREMENT REPORT message(s) received from the UE and/or on Radio Resource Management (RRM) criterion. The source eNB either issues a HANDOVER REQUEST message directly to the target eNB, or a HANDOVER REQUIRED message to the Mobile Management Entity (MME) which is relayed towards the target eNB as a HANDOVER REQUEST message, passing necessary information to prepare the handover at the target side.
In a third step, the target eNB configures the required radio resources, and optionally reserves a Random Access CHannel (RACH) preamble. The target eNB acknowledges the handover request by either sending back a HANDOVER REQUEST ACKNOWLEDGE message directly to the source eNB, or a HANDOVER REQUEST ACKNOWLEDGE message to the MME which is relayed towards the source eNB as a HANDOVER COMMAND message. The HANDOVER REQUEST ACKNOWLEDGE or the HANDOVER COMMAND message includes an RRC container, namely an RRC CONNECTION RECONFIGURATION message, to be transparently passed by the source eNB to the UE.
In a fourth step, the UE receives the RRC CONNECTION RECONFIGURATION message with necessary parameters to switch to the target cell. The UE performs synchronization to the target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was reserved, or following a contention-based procedure if no dedicated preamble was indicated.
In a fifth step, the target eNB responds with uplink allocation and timing advance value. When the UE has successfully accessed the target cell, the UE sends the RRC CONNECTION RECONFIGURATION COMPLETE message to the target eNB. The target eNB can now begin sending data to the UE.
In a sixth and last step, the target eNB informs the source eNB about the success of the handover procedure by sending a UE CONTEXT RELEASE message, which triggers the release of resources by the source eNB.
The data plane (or user plane) handling takes the following principles into account to avoid data loss during handover.
During handover preparation, tunnels can be established between the source eNB and the target eNB. For each Evolved-Radio Access Bearer (E-RAB) for which data forwarding is applied, one tunnel is established for upstream data forwarding and another tunnel is established for downstream data forwarding.
During handover execution, user traffic can be forwarded from the source eNB to the target eNB.
Upon handover completion, the target eNB sends a PATH SWITCH message to the MME to inform the MME that the UE has gained access to the target cell. The MME sends a USER PLANE UPDATE REQUEST message to the Serving-GateWay (S-GW), and the downstream data plane is switched by the S-GW from the source eNB to the target eNB.
In-sequence delivery and duplicate avoidance of data traffic is important to guarantee the effective operation of the transport protocol, such as the Transport Control Protocol (TCP) used over the Internet. In E-UTRAN, in-sequence delivery and duplicate avoidance function is guaranteed by the Packet Data Convergence Protocol (PDCP) layer. For in-sequence delivery and duplicate avoidance, a PDCP Sequence Number (SN) is maintained on a per bearer basis.
The source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the upstream PDCP Sequence Number (SN) receiver status and the downstream PDCP SN transmitter status of E-RABs for which PDCP status preservation applies, i.e. for Radio Link Control—Acknowledged Mode (RLC-AM) transmission. The upstream PDCP SN receiver status includes the PDCP SN of the first missing upstream data packet, and may include a bit map of the receive status of the out of sequence upstream data packets that the UE needs to retransmit in the target cell. The downstream PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new downstream data packets not having a PDCP SN yet. The source eNB may omit sending the SN STATUS TRANSFER message if none of the E-RABs of the UE shall be treated with PDCP status preservation.
During handover execution, the source eNB forwards in order to the target eNB all downlink PDCP Service Data Units (SDU) with their SN that have not been acknowledged by the UE. In addition, the source eNB also forwards without a PDCP SN fresh data arriving from the S-GW to the target eNB.
The source eNB forwards to the S-GW the upstream PDCP SDUs successfully received in-sequence until the sending of the SN STATUS TRANSFER message to the target eNB. Then at that point of time the source eNB stops delivering upstream PDCP SDUs to the S-GW and shall discard any remaining upstream RLC Protocol data Unit (PDU).
The source eNB shall either discard the upstream PDCP SDUs received out of sequence if the source eNB has not accepted the request from the target eNB for upstream forwarding or if the target eNB has not requested upstream forwarding for the bearer during the handover preparation procedure, or shall forward to the target eNB the upstream PDCP SDUs received out of sequence if the source eNB has accepted the request from the target eNB for upstream forwarding for the bearer during the handover preparation procedure.
The target eNB first re-transmits downstream PDCP SDUs forwarded by the source eNB through X2 before sending fresh data from the S-GW, with the exception of PDCP SDUs of which the reception was already acknowledged by the UE.
In order to assist the reordering function in the target eNB, the S-GW shall send one or more end-marker downstream packets on the old path immediately after switching the path. The end-marker packets shall not contain user data.
Upon receipt of the RRC CONNECTION RECONFIGURATION COMPLETE message, the target eNB starts transmitting upstream data packets received in sequence to the S-GW from the SN indicated in the SN TRANSFER STATUS message.
Release 10 of 3GPP has introduced Relay Nodes (RN) for extending the radio coverage to (mostly rural) areas where backhauling infrastructure are non-existent or deficient. E-UTRAN supports radio nodes relaying by having an RN wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface.
The RN supports the eNB functionality, meaning it terminates the radio protocols of the E-UTRA radio interface and the S1 and X2 interfaces.
In addition to the eNB functionality, the RN also supports a subset of the UE functionality so as to wirelessly connect to the DeNB.
The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (i.e., eNBs, MMES and S-GWs). S1 and X2 proxy functionality includes passing S1 and X2 data and control packets between S1 and X2 interfaces associated with the RN and S1 and X2 interfaces associated with other network nodes. Therefore, the DeNB appears to the RN as an MME or an S-GW for S1 interface, or as an eNB for X2 interface.
The PDCP layer at the RN performs in-sequence delivery and duplicate avoidance functions for upstream traffic received from the UE. The RN wirelessly connects to the DeNB, hence the PDCP layer at the DeNB also performs in-sequence delivery and duplicate avoidance functions for upstream traffic received from the RN.
During handover execution, the RN generates the SN STATUS TRANSFER message based on the last PDCP PDU received in sequence over the Uu interface. The PDCP SDU received in-sequence are placed in the transmission buffer for further transmission over the Un interface to the DeNB. From the RN point of view, the data in the transmission buffer are assumed to be delivered to the S-GW. Over the Un interface, the data may require Automatic Repeat reQuest (ARQ) retransmission for correct delivery to the DeNB due to impairments over the radio channel. Even if the RN stops transmitting upstream data packets after issuing the SN STATUS TRANSFER message, the DeNB does not stop the delivery of upstream data packets to the S-GW. After successful handover, the target eNB transmits upstream data packets that are received in sequence to the S-GW. Meanwhile, the DeNB may also deliver any pending upstream data packets to the S-GW. Therefore, it is possible for the S-GW to receive upstream data packets from the DeNB and the target eNB at the same time, or the upstream data packets delivered from the target eNB may arrive at the S-GW prior to the arrival of upstream data packets from the DeNB. This results in upstream data packets arriving at the S-GW out of sequence, which in turn may severely impact data transport on account of e.g. TCP congestion avoidance algorithm.